Follow-up to P2546, "Debugging Support" #7642

hubert-reinterpretcast · 2025-02-14T00:05:01Z

Follow-up to #6681 (P2546R5) from thread beginning with edit/2023/11/0870.

The notes in the paper make statements of fact about behaviour that, normatively, is implementation-defined. These should instead be statements of intent.
The description of breakpoint assumes that a debugger is present (and should instead cover both cases).
The odd restriction on how the debugger resumes execution of the program needs elaboration.
The description of the implementation strategy of is_debugger_present for POSIX makes assumptions that are more appropriate for the LSB.
The terminology used in the LSB is "tracing process", not "tracer parent process".
The note in is_debugger_present implies the wrong trade-off when it is unknown whether a debugger is present. Clarify to prefer returning false.

The note in `breakpoint` makes a statement of fact about the implementation-defined behaviour. The statement is actually one of intent.

Regarding `breakpoint`: The specific claim that the debugger resumes execution of the program as if the function was not invoked is confusing considering that the debugger may effect side-effects or cause execution to resume from a different evaluation. Instead, the idea is that `breakpoint` is not responsible for causing the translation process to make special accomodations for resumption of execution other than in cases where the debugger was strictly used for observation only.

Describe the possibility of abend.

The note in the description of `is_debugger_present` reads as a statement of fact about the normatively implementation-defined behaviour. Fix this to read as a statement of intent.

The functionality ascribed to POSIX by the wording is not present in POSIX. Update to reference the LSB and to use the corresponding terminology.

The wording implies a preference to return `true` in case it is unknown whether a debugger is present. Add a critical "only" to fix that.

hubert-reinterpretcast · 2025-02-14T02:14:53Z

@jwakely @grafikrobot, this is the follow-up from the November 2023 discussion.

Dani-Hub · 2025-02-14T06:36:07Z

@hubert-reinterpretcast What is the meaning of "abend" in the program can abend? Should that be "terminate" instead? (I think we have banned the word "abort" unless we specifically refer to std::abort)

W-E-Brown · 2025-02-14T06:56:07Z

"Abend" is a shortened form of "abnormal end." The term is of fairly long standing; I recall it from at least the 1960's when it was used by and in connection with IBM 360 systems software, and it may date from even earlier. When a program "abends," it terminates, often (typically?) for unforeseen reasons.

…

On 2025-02-14, at 12:36 AM, Daniel Krügler ***@***.***> wrote: Dani-Hub left a comment (cplusplus/draft#7642) @hubert-reinterpretcast What is the meaning of "abend" in the program can abend? Should that be "terminate" instead? (I think we have banned the word "abort" unless we specifically refer to std::abort) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. <https://github.com/hubert-reinterpretcast> <#7642 (comment)> <https://github.com/notifications/unsubscribe-auth/AAY4ZGMRRAWMSM6GSSPGWNT2PWFHPAVCNFSM6AAAAABXDNJCRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJYGM4TQNZVGM> Dani-Hub left a comment (cplusplus/draft#7642) <#7642 (comment)> @hubert-reinterpretcast <https://github.com/hubert-reinterpretcast> What is the meaning of "abend" in the program can abend? Should that be "terminate" instead? (I think we have banned the word "abort" unless we specifically refer to std::abort) — Reply to this email directly, view it on GitHub <#7642 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAY4ZGMRRAWMSM6GSSPGWNT2PWFHPAVCNFSM6AAAAABXDNJCRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJYGM4TQNZVGM>. You are receiving this because you are subscribed to this thread.

jwakely · 2025-02-14T07:42:27Z

I agree it's an established term, but if it's not well known then it doesn't help in a note that's intended to add clarification. Otherwise this looks like a good improvement.

Dani-Hub · 2025-02-14T07:56:17Z

"Abend" is a shortened form of "abnormal end." The term is of fairly long standing; I recall it from at least the 1960's when it was used by and in connection with IBM 360 systems software, and it may date from even earlier. When a program "abends," it terminates, often (typically?) for unforeseen reasons.

Thanks for the explanation. Could we possibly replace "the program can abend" by "the program can end abnormally" instead?

source/diagnostics.tex

Address review feedback ("abend" is not a well-known term).

grafikrobot

Thank you @hubert-reinterpretcast for the improved wording.

jensmaurer

Did I mention that I was opposed to adding those functions to start with? A note is obviously not the right tool to specify them, but we lack the normative framework to put the specification in a "recommended practice". (end of rant)

@jwakely should see this change.

jensmaurer · 2025-02-16T20:07:16Z

source/diagnostics.tex

+only when tracing the execution of the program with a debugger. On Windows or
+equivalent systems, this can be achieved by calling the
+\tcode{::IsDebuggerPresent()} Win32 function. For systems compatible with
+ISO/IEC 23360:2021, this can be achieved by checking for a tracing process, with


This replaces "POSIX" with "Linux Standard Base". Is there a particular reason for that? Does POSIX not cover the needed functionality?

Although ptrace is present in most UNIX-like systems, it isn't part of POSIX. The LSB is a much narrower scope than POSIX, but it is a standard, unlike families like "BSD" or "SysV". So if we want a standard that includes ptrace, LSB makes sense.

However, the wording never mentions prrace it just talks about "tracing" and "a tracer parent process" which is still meaningful even in e.g. HP-UX which replaced ptrace with ttrace, and in Solaris through ptrace but also via procfs. So maybe it's OK.

However, the wording never mentions prrace it just talks about "tracing" and "a tracer parent process" which is still meaningful even in e.g. HP-UX which replaced ptrace with ttrace, and in Solaris through ptrace but also via procfs. So maybe it's OK.

Using "POSIX" in conjunction with the handwaving implies that the handwaving is necessarily meaningful for all possible implementations of POSIX. That it is probably meaningful for extant implementations of POSIX does not make me feel any better about using "POSIX" without qualification.

jwakely

I don't love the change to refer to the LSB. What does it imply for e.g. macOS, which is not Windows and isn't compatible with the LSB either?

Not that "On POSIX" was really great wording either.

hubert-reinterpretcast · 2025-02-16T23:21:21Z

I don't love the change to refer to the LSB. What does it imply for e.g. macOS, which is not Windows and isn't compatible with the LSB either?

Not that "On POSIX" was really great wording either.

I would like to err on the side of "saying nothing wrong". Which is to say that, saying nothing for macOS (or any other non-Windows, non-LSB platform) leaves people the freedom to see whether the LSB implementation hint can be adapted for macOS, etc. without implying that the hint is applicable in cases where it isn't.

jwakely · 2025-02-16T23:33:21Z

Yeah that makes sense

hubert-reinterpretcast · 2025-02-25T03:04:39Z

@jensmaurer @jwakely, are we good with the current proposed change then?

tkoeppe · 2025-03-15T20:00:13Z

Is all this to be squashed?

jensmaurer · 2025-03-15T20:26:57Z

Yes, please squash and fix the commit message.

Hubert Tong added 6 commits February 13, 2025 17:44

Re-word breakpoint to fix untrue statement-of-fact

6e3a4b5

The note in `breakpoint` makes a statement of fact about the implementation-defined behaviour. The statement is actually one of intent.

breakpoint when no debugger is present

d817067

Describe the possibility of abend.

is_debugger_present: Fix unsupported statement-of-fact

4d24c66

The note in the description of `is_debugger_present` reads as a statement of fact about the normatively implementation-defined behaviour. Fix this to read as a statement of intent.

is_debugger_present: ptrace is not POSIX; LSB uses "tracing process"

a5c7585

The functionality ascribed to POSIX by the wording is not present in POSIX. Update to reference the LSB and to use the corresponding terminology.

is_debugger_present: Clarify intent to avoid false positives

67706d2

The wording implies a preference to return `true` in case it is unknown whether a debugger is present. Add a critical "only" to fix that.

hubert-reinterpretcast commented Feb 14, 2025

View reviewed changes

source/diagnostics.tex Outdated Show resolved Hide resolved

Replace newly added "abend"

cb8fc31

Address review feedback ("abend" is not a well-known term).

hubert-reinterpretcast changed the title ~~P2546 follow up~~ Follow-up to P2546, "Debugging Support" Feb 14, 2025

grafikrobot approved these changes Feb 15, 2025

View reviewed changes

tkoeppe requested review from Dani-Hub and jensmaurer February 15, 2025 13:50

Dani-Hub approved these changes Feb 16, 2025

View reviewed changes

jensmaurer reviewed Feb 16, 2025

View reviewed changes

jensmaurer requested a review from jwakely February 16, 2025 20:09

jwakely reviewed Feb 16, 2025

View reviewed changes

jwakely approved these changes Feb 25, 2025

View reviewed changes

jensmaurer approved these changes Feb 25, 2025

View reviewed changes

jensmaurer added the after-motions Pull request is to be applied after the pending edits from WG21 straw polls have been applied. label Feb 25, 2025

jensmaurer added this to the post-2025-02 milestone Feb 25, 2025

jensmaurer assigned tkoeppe Feb 25, 2025

tkoeppe merged commit ec10aae into cplusplus:main Mar 15, 2025
2 checks passed

Follow-up to P2546, "Debugging Support" #7642

Follow-up to P2546, "Debugging Support" #7642

Uh oh!

Conversation

hubert-reinterpretcast commented Feb 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hubert-reinterpretcast commented Feb 14, 2025

Uh oh!

Dani-Hub commented Feb 14, 2025

Uh oh!

W-E-Brown commented Feb 14, 2025 via email

Uh oh!

jwakely commented Feb 14, 2025

Uh oh!

Dani-Hub commented Feb 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

grafikrobot left a comment

Choose a reason for hiding this comment

Uh oh!

jensmaurer left a comment

Choose a reason for hiding this comment

Uh oh!

jensmaurer Feb 16, 2025

Choose a reason for hiding this comment

Uh oh!

jwakely Feb 16, 2025

Choose a reason for hiding this comment

Uh oh!

hubert-reinterpretcast Feb 16, 2025

Choose a reason for hiding this comment

Uh oh!

jwakely left a comment

Choose a reason for hiding this comment

Uh oh!

hubert-reinterpretcast commented Feb 16, 2025

Uh oh!

jwakely commented Feb 16, 2025

Uh oh!

hubert-reinterpretcast commented Feb 25, 2025

Uh oh!

tkoeppe commented Mar 15, 2025

Uh oh!

jensmaurer commented Mar 15, 2025

Uh oh!

Uh oh!

Uh oh!

hubert-reinterpretcast commented Feb 14, 2025 •

edited

Loading

Dani-Hub commented Feb 14, 2025 •

edited

Loading